Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/answers/comp/pc-hardware-faq/part2

Text File | 1994-04-11 | 56KB | 1,161 lines

Path: bloom-beacon.mit.edu!hookup!news.moneng.mei.com!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!noc.near.net!chpc.chpc.org!chpc.chpc.org!not-for-mail
From: [e-mail] (Ralph Valentino)
Newsgroups: comp.sys.ibm.pc.hardware.video,comp.sys.ibm.pc.hardware.comm,comp.sys.ibm.pc.hardware.storage,comp.sys.ibm.pc.hardware.cd-rom,comp.sys.ibm.pc.hardware.systems,comp.sys.ibm.pc.hardware.networking,comp.sys.ibm.pc.hardware.chips,comp.sys.ibm.pc.hardware.misc,comp.answers,news.answers
Subject: comp.sys.ibm.pc.hardware.* Frequently Asked Questions (FAQ) Part 2/5
Followup-To: comp.sys.ibm.pc.hardware.misc
Date: 11 Apr 1994 01:33:42 -0400
Organization: Center For High Performance Computing
Lines: 1138
Sender: [e-mail]
Approved: [e-mail]
Distribution: world
Expires: 11 May 1994 00:00:00 GMT
Message-ID: <2oanfm$[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: localhost.chpc.org
Summary: This is a monthly posting containing a list of Frequently
     Asked Questions (and their answers) pertaining to hardware
     and IBM PC clones.  It should be read by anyone who wishes
     to post to any group in the comp.sys.ibm.pc.hardware.*
     hierarchy.
Xref: bloom-beacon.mit.edu comp.sys.ibm.pc.hardware.video:6700 comp.sys.ibm.pc.hardware.comm:2486 comp.sys.ibm.pc.hardware.storage:5012 comp.sys.ibm.pc.hardware.cd-rom:3343 comp.sys.ibm.pc.hardware.systems:2887 comp.sys.ibm.pc.hardware.networking:1848 comp.sys.ibm.pc.hardware.chips:5014 comp.sys.ibm.pc.hardware.misc:4921 comp.answers:4845 news.answers:17889

Archive-name: pc-hardware-faq/part2
Last-modified: 1994/04/10
Version: 1.3

S) 3.0 IO controllers/interfaces

Q) 3.1  *How do IDE/MFM/RLL/ESDI/SCSI interfaces work?

Q) 3.2  *How can I tell if I have MFM/RLL/ESDI/IDE/SCSI?

Q) 3.3  Do caching controllers really help?

[From: backbone![e-mail] (Wayne Schlitt)]

The short answer, is that if you are using a multi-tasking
operating system with a good memory manager, caching controllers
should be ignored.  If you are running DOS or Windows, then *maybe*
they will help, but I am not sure that they are a good buy.

There are lots of people who have said "I put a caching controller in
my computer, and it runs faster!".  This is probably true, but they
never have measured the speed increase compared to putting the same
memory into main memory instead.  More importantly, the caching
controllers cost more money than non caching controllers, so you
should be able to add _more_ main memory instead of buying a caching
controller.

The following is a shortened up version of a much longer article.  If
you want a copy of the longer article, send me email at
"[e-mail]".

*** Why a multi-tasking operating system?

A multi-tasking operating system can allow the application to continue
immediately after it does a write, and the actual disk write can
happen later.  This is known as write behind.  The operating system
can also read several blocks from the file when the application
requests just part of the first block.  This is known as read a head.
When the application requests the block later on, the block will
already be there and the OS can then schedule some more reads.

A multitasking operating system is required because these operations
can cause interrupts and processing when control has been given back to
the application.

Basically, operating systems such as DOS, MS-Windows, MacOS and such
do not allow true preemptive multitasking and can not do the read a
heads and the write behinds.  For these systems, the latency of a disk
drive is the most important thing.  The application does not regain
control until the read or write has finished.

*** The controller can't speed up the disk.

Remember, the bottleneck is at the disk.  Nothing that the controller
can do can make the data come off the platters any faster.  All but the
oldest and slowest controllers can keep up with all but the newest and
fastest disks.  The SCSI bus is designed to be able to keep *several*
disks busy without slowing things down.

Speeding up parts of the system that are not the bottleneck won't help
much.  The goal has to be to reduce the number of real disk accesses.

*** First, isn't the caching controller hardware and isn't hardware
*** always faster than software?

Well, yes there is a piece of physical hardware that is called the
caching controller, but no, the cache is not really "in hardware".
Managing a disk is a fairly complicated task, complicated enough that
you really can't implement the controller in combinatorial logic.

So, just about all disk controllers and for that matter all disk
drives have a general purpose computer on them.  They run a little
software program that manages the communication between the main cpu
and the disk bus, or the disk bus and the disk.  Often this cpu is put
in with a bunch of other logic as part of a standard cell custom chip,
so you might not see a chip that says "Z80" or such.

So, we are really not comparing "hardware" with "software", we are
comparing "software on the controller" with "software on the main
cpu".

*** Ok, why can the OS win?

Assume that you have a bunch of memory that you can either put into
main memory and have the OS manage the cache, or put on a caching
controller.  Which one will be better?  Let us look at the various
cases.

For a cache hit you have:

If the OS does the caching, you just have the OS's cache checking
latency.

If the card does the caching, you will have the OS's cache checking
latency, plus the I/O setup time, plus the controller's cache checking
latency, plus you have to move the data from the card to main memory.
If the controller does DMA, it will be taking away from the memory
bandwidth that the main CPU needs.  If the controller doesn't have
DMA, then the main CPU will have to do all the transfers, one word at
a time.

For a cache miss, you have:

If the OS does the caching, you have the OS's cache checking latency
plus the set up time for the disk I/O, plus the time it takes for the
disk to transfer the data (this will be a majority of the time), plus the
cost of doing either the DMA or having the CPU move the data into main
memory.

The caching controller will have all of the above times, plus it's own
cache checking latency.

As you can see, the caching controller adds a lot of overhead no
matter what.  This overhead can only be offset when you get a cache
hit, but since you have the same amount of memory on the controller
and the main cpu, you should have the same number of cache hits in
either case.  Therefore, the caching controller will always give more
overhead than an OS managed cache.

*** Yeah, but there is this processor on the controller doing the
*** cache checks, so you really have a multi-processor system.
*** Shouldn't this be faster than a single processor?  Doesn't this
*** allow the main cpu to do other things while the controller manages
*** the cache?

Yes, this really is a multi-processor system, but multi-processors are
not always faster than uni-processors.  In particular, multi-processor
systems have communication overhead.  In this case, you are
communicating with the controller using a protocol that is fairly
expensive, with outb instructions and interrupts and such.  The
overhead of communicating with this other processor is greater than
the overhead of just checking the cache on main cpu, even if the main
cpu is very slow.

The multi-processor aspect just doesn't help out when you are talking
about managing a cache.  There is just too much communication overhead
and too little processing for it to be a win.

*** Ok, but couldn't the caching controller do a better job of
*** managing the cache?

Both the controller and the OS are going to be executing a piece of
software, so in theory there isn't anything that the slower cpu on the
controller can do that the OS can't do, but the OS can do things that
the controller can't do.

Here are some of the things that the OS can do better:

* When you read a block from a file, the OS can read several more
  blocks ahead of time.  Caching controllers often will read an entire
  track in order to simulate this file read a head, but the rest of
  the file isn't always on the same track, only the OS knows where the
  blocks are really going to be at.  This can lead to wasted time and
  cache memory reading data that will never be used.

* In order to improve file system reliability, some writes _must_
  complete immediately, and _must_ complete in the order that they are
  given.  Otherwise, the file system structures may not be left in a
  coherent state if the system crashes.

  Other writes can be completed as time is available, and can be done
  in any order.  The operating system knows the difference between
  these cases and can do the writes appropriately.

  Caching controllers, on the other hand, don't know if the write that
  it was just given _must_ be written right away, or if it can wait a
  little bit.  If it waits when it shouldn't, you are risking your
  file system and data.

* Sometimes, you want a large disk cache if you are accessing lots of
  data off the disk.  At other times, you want a small disk cache and
  more memory left to programs.  The operating system can balance
  these needs dynamically and adjust the amount of disk cache
  automatically.

  If you put the memory on a caching controller, then that memory can
  _only_ be used for disk caches, and you can _never_ use more.
  Chances are, you will either have too much or too little memory
  dedicated to the cache at any give time.

* When a process closes a file, the operating system knows that the
  blocks associated with that file are not as likely to to be used
  again as those blocks associated with files that are still open.
  Only the operating system is going to know when files are closed,
  the controller won't.  Similar things happen with processes.

* In the area of Virtual Memory, the OS does an extremely better job
  of managing things.  When a program accesses a piece of memory, the
  CPU will do a hardware level check to see if the page is in memory.
  If the page is in memory, then there will basically be no delay.  It
  is only when the page isn't in memory that the OS gets involved.

  Even if all of those extra pages are sitting in the
  caching controller's memory, they still have to be moved to main
  memory with all the overhead that that involves.

  This is why dynamic caches vs program memory is so important.

*** What is the "Memory Hierarchy" and how does this relate to
*** caching controllers?

The basic idea of a memory hierarchy is to layer various types of
memory, so that the fastest memory is closest to the cpu.  Faster
memory is more expensive, so you can't use only the fastest type and
still be cheap.  If a piece of data isn't in the highest (fastest)
level of the hierarchy, then you have to check the next level down.

In order for a memory hierarchy to work well, you need to make sure
that the each level of the hierarchy has much more storage then the
level above it, otherwise you wont have a high hit rate.

The hierarchy on a 486 goes something like this:

8 regs << 8k on chip cache << 256k off chip cache << main memory << disk

If you are going to put something between main memory and disk, it
needs to be much larger than main memory in order for it to be
effective.

*** What about all these neat things that a caching controller can do
*** such as elevator seeking, overlapping seeks with reads and writes,
*** scatter/gather, etc...

These are nice features, but they are all done by either the OS or a
good SCSI controller anyway.  None of these things are at all related
to supporting the cache, so you shouldn't buy a caching controller for
just these features.

*** Ok, you have talked about things like Unix, OS/2 and Windows NT,
*** but what about DOS and MS-Windows?

Well, here things get a lot grayer.  First, older versions of DOS have
notoriously bad disk cache programs.  Since neither DOS nor MS-Windows
are preemptive multi-tasking systems, it is much harder to do read a
head.  Also, since DOS/MS-Windows users are used to being able to
power off their computers at any time, doing write behind is much more
dangerous.  DOS and MS-Windows also can crash much easier than these
other OS's, so people might reboot for many reasons.

Caching controllers usually leave the hard disk light on when they
have data that hasn't been written out, and people don't usually power
their computer off until that light goes out.  This lets the
controllers do write behind fairly safely.  (But you can still loose
power, so this isn't risk free.)  They also do crude read a heads by
prereading entire tracks.

DOS also runs in real mode and real mode can only access 640K of
memory.  This mean that a disk cache can be real helpful.
Unfortunately, to do a software based disk cache, the cpu has to be
switched into protected mode in order to access memory beyond the 640K
boundary and then you have to switch back into real mode.  Intel,
however forgot to make it easy to switch back to real mode.   All in
all, this switching back and forth ends up being real expensive.  This
_might_ be more expensive than just using a caching controller, I
don't know.

So, it is possible that if you configure DOS to not use a cache, and
get a caching controller, then you might be a head.  I really don't
know much about this area.  I have not done any real timings of this.

*** So, when would you ever want to buy a caching controller?

The answer is not too often, but there are a few cases that I can
think of:

* You have filled up all your SIMM slots on your motherboard and in
  order to add more memory you would have to throw some out.  This is
  a real shaky reason.  You can always sell your old memory, or move
  it to another computer.  The jump from 4 1MB SIMMs to 4 4MB SIMMs is
  large, but you will be much better off in the long run with more
  main memory.

* You have maxed out your memory and you need it all for programs and
  data.  If you can't put any more memory on the mother board, then
  you don't have many choices.

* If you have a bunch of slow (100ns-120ns) memory left over from say
  a 286 or something and you can't use it on your motherboard because
  it is too slow, then maybe adding it to a caching controller
  will help.  Be careful however, if your hit rates on the caching
  controller are too low, then you may be just adding overhead without
  getting any benefits.

* If you are stuck with a bad OS because that's what your applications
  run on, then you might be better off with a caching controller.

*** What about those disk drives that come with caches, are they bad too?

Don't confuse caching disk controllers with cache on disk drives.  The
latter is actually useful.  The little cpu on the disk drive has to
read every byte that comes off the disk in order to see when the
sector that you are interested in has come under the heads and to do
any error detection and correction.  The disk also has to have buffers
in case the bus is busy, and to sync up the speeds of the bus and the
heads.

Since all this data is going though the cpu on disk drive and you have
to have a buffer anyway, just making the buffer larger and saving the
entire track is an easy win.  Saving a couple of the most frequent
tracks is also a win.

Most of these caches on the disk drives are fairly small (64k-256k),
and a single memory chip will give you about that amount of memory
anyway, so you aren't wasting many resources.  This also allows the OS
to always assume that interleaving is not necessary to get full disk
throughput, even if it does a fair amount of processing between disk
requests.

Q) 3.4  Do IDE controllers use DMA?

No, they do not.  This is a rumor that keeps popping up.  This may
change on the next revision of the standard.

Q) 3.5  *How do I get an MFM/RLL/ESDI & IDE drive to coexist with each other?

Q) 3.6  Why won't my two IDE drives work together?

[From: [e-mail] (John Anthony Ruchak)]

Assuming that the drives are attached to the same controller and they
work properly when attached one-at-a-time, you probably don't have
them configured properly for Master/Slave operation.

When operating 2 IDE drives, one must be designated as "Master" and
the other as "Slave."  There are jumpers on every IDE drive to
configure this.  Check your hard drive manuals for the jumper settings
for your drives.  In general, it doesn't matter which is which - just
pick one as master, and make the other slave.

In your CMOS configuration, Drive 1 should have the parameters (heads,
cylinders, etc.) that match the drive you set as "Master" and Drive
2's parameters should match those of the "slave" drive.  In operation,
the Master will appear as drive C: and the slave as drive D:.

Because not all hard drive manufacturers follow the IDE specifications
closely enough, drives from 2 different manufacturers may not work well
together.  In this case, changing master -> slave and slave -> master
(along with the appropriate CMOS changes) may help.  If it doesn't,
then trying two drives from the SAME manufacturer is the only avenue
you have left.

Q) 3.7  *Which is better, VLB or ISA IDE?

Q) 3.8  How do I install a second controller?

[From: [e-mail] (PAUL LESLIE STROPLE)]

The following should solve about 95% (9.5?) of second controller
problems, if only to tell you it can't be done!

Generic Second Controller Installation:

1) Normally the MFM/IDE/RLL controller is set up as the primary, and
the ESDI/SCSI as the secondary; One reason for this is because the
ESDI/SCSI controller cards are usually more flexible in their set up
and secondly this method seems to work (probably due to reason one).

2) Your primary controller is set up using all the normal defaults:
   - Floppy  at primary address(3F0-3F7).
   - Hard disk enabled, at primary addresses (1F0-1F7),
BIOS address C800 and interrupt 14.

3) Your secondary controller is set up as:
   - Floppy drives disabled
   - Hard disk controller enabled, secondary address(170- 177) and
     interrupt 15.
   - NOTE: onboard bios set to D400, or D800 can be used, if there is a
     conflict.

4) Computer BIOS Setup:
   - Any drive(s) on the primary controller (MFM/IDE), should be
     entered in the BIOS setup as usual.
   - You DO NOT enter the drive types for the hard disks on the
secondary controller, even if there are only two drives in the entire
system i.e., if one drive on each controller you only enter the drive
type of the hard disk on the primary controller -- the 2nd drive type
is left as not installed (0).

Operating System:

If you do the above steps you now have the hardware setup correctly;
your only other problem may be with the operating system.

Different OSs handle secondary controllers differently; as well,
different controllers handles same OSs differently (scared yet?).

For example: with DOS you may require a device driver (available from
the manufacture or through third party companies, such as Ontrack
Computer Systems -- more on Ontrack later). Some flavors of UNIX
handle a mixture of controllers better than others (e.g., IA 5.4 had
probs mixing ESDI and SCSI controllers under certain conditions).

Procedure:

You should verify that your secondary controller, and associated hard
drives, are working properly (you can try this by installing it as the
primary system -- removing existing system first!).  Follow above
steps 1 to 4, pray, and turn on system! If it still won't work you may
need additional drivers. First check with the supplier or manufacture
(I know, for example, a DTC ESDI controller comes with the DOS drivers
included, and it works perfectly).

I am not sure of operating systems supported by Ontrack Data Systems.
I know that their DOS driver can assist secondary controllers, even
allowing two IDEs to co-exist. Likewise, the drivers can also install
virtually any drive, regardless of what is supported by the BIOS.

BIG NOTE: The features required in a secondary controller a normally
not found on a $30.00 IDE controller. The best thing to do it, if
possible, is to get a guarantee from the supplier/manufacture that if
it doesn't work (and they can't make it) then they will take it back.

Ontrack supplies a complete range of hard disk products and services
-- from driver software, data recovery services, to media and data
conversions (including tape backups).  The product I know them from is
DiskManager.

Disk Manager is a utility for hard disk management. It will allow you
to setup and install virtually any hard disk, regardless of disk's
layout and BIOS options available. Disk Manager (version greater than
5.2.X, or there abouts) includes a driver for co-resident controllers.
For driver to work the co-res board must be able to hit the above
addresses and must be WD1003 AT command set compatible (this includes
most IDE and ESDI boards).

DM contains a number of features, including full diagnostics.  You may
not need to know the disk's geometry, as there are numerous layouts
stored internally. All you need to do is select the correct model and
DM does the rest.

To contact Ontrack: U.S.  (800)-872-2599; UK 0800-24 39 96 this is
either an address or phone number! outside U.K. (but NOT U.S.)
44-81-974 5522

Q) 3.9  Which is better, SCSI or IDE?

[From: [e-mail] (Ralph Valentino)]

IDE vs SCSI

Non-issues:
1) SCSI and IDE devices cost approximately the same for the same
   features (size, speed, access time).  Shop around for good prices.

Advantages of IDE:
1) faster response time (low request overhead)
2) hard drive interface is compatible with RLL/MFM/ESDI: any driver
for one (including the main system BIOS) will run the other.
3) IDE controllers are considerably cheaper ($150 and up) than SCSI
   host adapters.
4) Will always be the boot device when mixed with SCSI.

Advantages of SCSI:
1) Supports up to 7 devices per host adapter.  This saves slots,
IRQ's, DMA channels and, as you add deviceds, money.
2) Supports different types of devices simultaneously the same host
adapter (hard drives, tape drives, CDROMs, scanners, etc).
3) SCSI devices will work in other systems as well (Mac, Sparc, and
countless other workstations and mainframes).  If you change platforms
in the future, you will still be able to use your SCSI devices.
4) Automatically configures device type, geometry (size), speed and
even manufacturer/model number(SCSI-2).  No need to look up CMOS
settings.
5) Busmastering DMA (available in all but a few cheap SCSI host
adapters) decreases amount of CPU time required to do I/O, leaving
more time to work on other tasks (in multitasking OS's only).
6) Software portability - drivers are written for the host adapter,
not the specific device.  That is, if you have a CDROM driver for your
host adapter, you can purchase any brand or speed SCSI CDROM drive and
it will work in your system.
7) Will coexist with any other type of controller (IDE/RLL/MFM/ESDI)
or host adapter (other SCSI cards) without any special tricks.  SCSI
host adapters do not take up one of the two available hard drive
controller port addresses.
8) greater bandwidth utilization (higher throughput) with multiple
devices.  Supports pending requests, which allows the system to
overlap requests to multiple devices so that one device can be seeking
while the second is returning data.
9) Ability to "share" devices between machines by connecting them to
the same SCSI bus.  (note: this is considerably more difficult to do
than it sounds).
10) Bridges are available to hook RLL and ESDI drives to your SCSI host
adapter.  (note: these tend to be prohibitively expensive, though).

Warnings:
1) With otherwise equal drives, IDE will perform better in DOS due to
low command overhead.  SCSI, however, will perform better in
multitasking OS's (OS/2, Unix, NT, etc).  If you see speed comparisons
(benchmarks), make sure you know what OS they were run under.
2) Most benchmarks only test one aspect of your system at a time, not
the effect various aspects have on each other.  For instance, an IDE
drive may get faster throughput but hurt CPU performance during the
transfer, so your system may actually run slower.  Similar confusions
arise when comparing VLB and EISA host adapters.
3) When comparing two systems, keep in mind that CPU, memory, cache,
and bus speed/type will all effect disk performance.  If someone gets
great I/O performance with a particular controller/drive combination
on his Pentium, you should not expect your 386SX-25 to get such I/O
performance even with the exact same controller/drive combination.
4) Similarly sized or even priced drives may not perform equally, even
if they're made by the same manufacturer.  If you're going to compare
two drives, make sure they have the exact same model number.  (IDE
drives usually have an 'A' and SCSI drives usually have an 'S'
appended to their model number).

Q) 3.10  Can MFM/RLL/ESDI/IDE and SCSI coexist?

The PC is limited to two drive controllers total.  SCSI, however, is a
"host adapter" and not a drive controller.  To the rest of your
system, it appears more like an ethernet card than a drive controller.
For this reason, SCSI will always be able to coexist with any type
dive controller.  The main drawback here is that on most systems, you
must boot off a disk on the primary drive controller, if you have one.
That means if you have SCSI and IDE in your system, for example, you
can not directly boot from the SCSI drive.  There are various ways to
get around this limitation, including the use of a boot manager.

Q) 3.11  What's the difference between SCSI and SCSI-2? Are they compatible?

The main difference between SCSI and SCSI-2 are some new minor
features that the average person will never notice.  Both run at a
maximum 5M/s.  (note: Fast and Wide SCSI-2 will potentially run at
faster rates).  All versions of SCSI will work together.  On power up,
the SCSI host adapter and each device (separately) determine the best
command set the speed that each is capable of.  For more information
on this, refer to the comp.periphs.scsi FAQ.

Q) 3.12  Can I share SCSI devices between computers?

There are two ways to share SCSI devices.  The first is removing the
device from one SCSI host adapter and placing it on a second.  This
will always work if the power is off and will usually work with the
power on, but for it to be guaranteed to work with the power on, your
host adapter must be able to support "hot swaps" - the ability to
recover from any errors the removal/addition might cause on the SCSI
bus.  This ability is most common in RAID systems.

The second way to share SCSI devices is by connecting two SCSI busses
together.  This is theoretically possible, but difficult in practice,
especially when disk drives are on the same SCSI chain.  There are a
number of resource reservation issues which must be resolved in the
OS, including disk caching.  Don't expect it to 'just work'.

Q) 3.13  How do I swap A: and B:

[From: [e-mail] (Ronald Geens)]

To swap A: and B: drives :
1) open up your machine to see if look at the cable that interconnects
the 2 drives.
2) if the cable is twisted, there is no problem, just switch the
connectors from 1 drive to the other.And change the bios-setup.
3) if the cable isn't twisted (which is very,very rare), it's a little
harder: leave the cables as they are, but change the jumpers on the
drive. (this sounds a lot tougher, but it can usually be done without
to much hassle.  When the cable connecting the 2 drives is just a flat
one (like the harddisk cable) then you must play with the jumpers on
the drives: Most of the time, there is a jumper with 4 pins, with the
following layout:
                               _
                              |1|
                 |2*3|
                              ---

Where the * is the 4th unnumbered pin. Normally the A: drive will have a
jumper on pin 2 & 4 and the B: drive on 1 & 4. Just change these jumpers
around, (i.e. new A: 2&4, new B: 1&4) and change the BIOS configuration.
4) Don't panic if it doesn't work, just make sure all cables are
conected properly and if that doesn't work just restore everything to
its old state.
PS. By twisted cable, I mean that between the A: and B: drive, a few
wires of the flat cable are turned around.

[From: [e-mail] (David Reeve Sward)]

I have found two ways to do this: I originally switched their
positions on the cable attached to the controller, and changed the
BIOS to reflect this.  I recently got a gsi model 21 controller for my
IDE drive, and this controller allows you to specify which drive is A:
and B: in software (it lights the LEDs in turn and asks which is A:
and which is B:).  This did not require a cable change (but I still
changed by BIOS).

Q) 3.14  What is a 16550 and do I need one?

The 16550 is a UART with two 16 byte FIFOs.  A UART is the part of a
serial port that takes byte-wide (characters) data and converts it to
bit-wide (serial) data, and visa versa.  The FIFO is a buffer which
can hold characters until the CPU is ready to remove it or until the
serial line is ready to transmit it.  The 'normal' UART in the PC (the
8250 or 16450) only has 1-byte FIFOs.  The additional 15 bytes can be
useful when the CPU is busy doing other things - if the CPU isn't able
to remove data fast enough, it will be lost.

A very important thing to note is that under DOS, the CPU doesn't have
anything else to do, so the 16550 is wasted.  Only under multitasking
operating systems does it really become useful.  The 16550 will *not*
make your file transfers any faster, it will only prevent data from
being lost and relieve your CPU of some overhead.  If you notice
system performance dropping like a rock when file transfers are
occurring, a 16550 may be helpful.  If you see re-transmissions (bad
packets) or "FIFO overrun's" during file transfers under a
multitasking OS, try the same thing under DOS - if the errors go away,
then chances are a 16550 will be useful.  If they remain, then your
problem is likely to be elsewhere.

Q) 3.15  *Are there any >4 serial port cards?

Q) 3.16  Should I buy an internal or external modem?

[From: [e-mail] (Arnoud Martens)]

While low speed modems are often only produced as an internal PC card,
most modem manufacturers provide two versions of their higher speed
modems:

1: internal ISA bus card, specially designed to work with the
standard PC bus. You just plug it in and configure it to use on
port.

2: external modem that has to be connected to the serial ports of
your PC (com 1-4), using a serial RS232 cable.

In most cases the functionality of these two is equal. There are
however some differences in using, maintaining and buying these
modems. It is very difficult to give an definite answer as to which one
is better, it completely depends on your own situation. Some of the
points that are in favor of an external modem are:

  * It has lights showing the status of the connection, this can be
    useful in those (rare) cases that you have problems with the
    connection.

  * It can be used on a wide range of systems. External modems
    are connected using a RS232 cable, a standard that most computer
    systems support. So you can as easily use your external modem
    on a Mac, Amiga or Unix box as on your PC.

  * It doesn't consume power inside the PC (it uses a normal net
    adapter), and doesn't produce any heat inside your PC.

On the other hand the internal modem has also a couple of advantages
compared to an external modem:

  * It is always cheaper, Somewhere in the order of 10% less compared
    to the same external modem.

  * It doesn't need special serial hardware since it has already
    been integrated on the board, which will make it even more
    cheaper.

So basically if portability of your modem is an issue, you are better
of with an external modem. But if you only intend to use the modem
with your PC and don't have any power problems, an internal modem is
the best choice.

Q) 3.17  What do all of the modem terms mean?

[From: [e-mail] (Arnoud Martens)]

A modem (MOdulator-DEModulator) is a device capable of converting digital
data from your computer into an analog signal that is suitable for
transmission over low band width telephone lines. A modem thus makes it
possible to connect two computers over a telephone line and exchange data
between them.

Basically a modem picks up the phone, and dails a number. A modem on
the other side will pick up the phone and the two modems will
negotiate which protocol to use. When they agree the actual
transmission of data can begin.

The major feature of a modem is the speed that it can achieve
connecting to other modems. This speed is often expressed in baud or
bits per second. The first is a feature of the line and specifies how
much of the bandwidth of the phone channel is used and is fixed to
2400 baud. A baud is defined as the number of lines changes per
second. Bits per second is the actual amount of data transmitted in
one second. Most modems are capable of sending more than one bit per
line transition by using very intelligent signal modulation
techniques. So the bps can be eight times higher compared to trhe baud
rate.

The modulation techniques that a modem uses are standarized by the
ITU-T ( former CCITT), so that modems of different brands can connect
to each other as they use the same modulation schemes. These standards
are often incorporated in a protocol definition that is referred to by
the letter V followed by a number. The most common protocols are:

    V21: (300 baud)
    V22bis: (2400 baud)
    V32: (9600 baud)
    V32bis: (14400 baud)

A modem is often advertised only by its fastest protocol, most of these
modems "speak" slower protocols as well.

There are also standards on using data compression by the modem, such as MNP5
and V42bis, and error control protocols (V42 and MNP4). These standards can
reduce the transmitted data by a factor four, by using advanced compression
techniques.

To give you an idea a how fast fast is in modem technology: V32bis transmits
somewhat like 1600 characters per second (that is ~33% of 1 page of
text). Transferring a file of 1Mb takes about 12 minutes. Using V42bis can
speed up transmission to 4000 characters per second for uncompressed data.

Apart from these standardized protocols there are also faster protocols which
are supported by some modem manufacturers. But remember anything faster than
14k4 is *not yet* standarized, and often different manufacturers use their
own modulation scheme that allows only their own modems communicate at that
speed. The most common high speed protocols are:

    V32 terbo (19200 baud)
    V34 (28800 baud) or Vfast.

The standard for V34 is being worked on, it will be released somewhere in
1994. Some modem manufacturers already sell modems with the (prelimenary) V34
standard. If you are serious about buying a fast modem, upgradability to this
standard should be provided by the manufacturer.

When you use your modem it is important to differentiate between command
status and connect status of your modem. When you are connected to an another
modem everything you send to the modem, will be transmitted to the other
modem. In command mode everything you type will be recieved and interpreted
by the modem. Command mode allows you to change the default settings for
youyr modem.

In command mode it is likely that your modem will respond to the Hayes AT
command set. "AT commands" all have prefix AT, and can be used to change the
(default) settings of your modem. To check if your modem works, fire up a
terminal program (such as kermit), connect to your modem (in kermit c
[ENTER]) and issue AT [ENTER], if your modem works it should respond with
OK. For a list of all "AT commands" see the manual of your modem, as most AT
commands are modem specific.

If you buy a fax-modem, you should pay attention to a couple of things. First
the modem must support Class 2 fax commands, furthermore automatic fax mode
selection is a big pro. That means if you receive a call the modem is capable
of detecting a fax message or a modem connection and act properly (start up a
fax receiving program or spawn something like a login process on the
connection).

Finally there is no best modem to get, brands and qualities change very fast,
as do the prices. If you are interested in buying one, subscribe to the
newsgroup comp.dcom.modems, most postings in this group are very brand
oriented and you will recognize fast enough which users are satisfied over
their modems and which are not.

Q) 3.18  What kinds of sound cards are avalable?

This is covered in the comp.sys.ibm.pc.soundcard FAQ, archive name:
PCsoundcard/soundcard-faq.  Please refer to this document for more
information.

Q) 3.19  Where can I find EISA/VLB sound and IO cards?

Chances are that you won't be able to find them anywhere, and if you
do, they won't be worth the money.  Sound and IO cards have very low
bandwidth requirements, over 10 times lower than the ISA bandwidth and
over 60 times lower than the EISA bandwidth.  For this reason, there
is no advantage in placing them on the more expensive EISA/VLB cards
when the less expensive ISA will more than suffice, especially
considering than all ISA cards will work in an EISA/VLB slot.

Q) 3.20  +How does the keyboard interface work?


[From: [e-mail] (Joseph H Allen)]

The IBM keyboard is connected to the computer through a serial interface
similar to a COM port.  When you press a key, the keyboard sends a
"scan-code" for that key to the computer.  When you release the key, the
keyboard sends a release code to the computer.  If you hold down one key and
press and release another key, the computer will receive the scan-code for
the held key and a scan and release code for the other key.  Since the
release code for the held key was not received, the computer knows that the
held key was down while the other key was pressed.  In this way, the
computer can handle the Shift, Alt and Ctrl keys (and any key could work
like a shift key, since all keys work alike).  The ROM BIOS in the computer
buffers the data from the keyboard, translates the scan-codes to ASCII and
handles the operation of the shift and lock keys.  The keyboard itself also
has a small buffer and there is hardware flow-control for preventing
overruns.  All of this seems simple and quite elegant, but by the time we
get to the AT keyboard the details of the implementation are so complicated
as to ruin an otherwise ideal keyboard.

The XT keyboard's interface almost captures the above elegance (indeed it is
the only elegant thing about the XT, IMHO).  The interface uses a 5-pin DIN
connector with these signal assignments:

     1     CLK/CTS (open-collector)
     2     RxD
     3     RESET
     4     GND
     5     +5V

When the keyboard has a byte to send to the computer, it shifts 9 bits out
to the data line (RxD) with nine clock pulses on the CLK line.  The data
format is 1 start bit, followed by 8 data bits.  The baud rate is roughly
2000 bits per second and is not precisely defined.  Once a byte is
completely transmitted, the computer holds the Clear-To-Send (CTS) line low
to prevent the keyboard from sending any more bytes until the keyboard
interrupt handler reads the current one.  Usually a simple 9-bit clearable
TTL shift register is used to receive keyboard data.  The 9th bit of the
shift register is used to drive an open-collector buffer connected to the
CTS line.  When the start-bit gets all of the way through the shift
register, it holds the CTS line low itself.  Once the CPU reads the
assembled byte, it has only to clear the shift register to release the CTS
line and allow another byte to be received.  Three TTL chips or a single PAL
can implement an entire XT keyboard interface.

The data bytes which the XT sends are also simple.  Codes 0-127 are the
scan-codes.  Codes 128-255 are the release codes- they're the same as the
scan codes, but with the high bit set.  The XT keyboard has only 84 keys, so
not all of the scan-codes are used.

The only problems with the XT keyboard are the lock-status lights
(Caps-lock, Scroll-lock and Num-lock) and the key repeat mechanism.  The
lock-status lights can get out of sync with the computer's idea of which
lock keys are activated, but this only happens if someone resets the
keyboard by unplugging it temporarily.  When you hold a key down long
enough, the keyboard starts repeating the scan-code for that key.  The
release code is still only transmitted once, when the key is released.  The
problem here is that the delay to the start of the repeats and the repeat
rate were made too slow.  Of course, the keyboard really doesn't have to
handle repeat at all, since the computer knows when keys are pressed and
released and has a timer itself.  Old XT keyboard TSRs allowed you to adjust
the repeat delay and rate by duplicating the key repeat mechanism in the
computer.

Once IBM found that it had a nearly perfect keyboard it, of course, decided
that it had to be almost completely redesigned for the AT.  The keyboard
didn't have to be redesigned- there were enough extra scan-codes for the
AT's 101 key keyboard and the repeat mechanism could simply have been moved
to the BIOS.  But no, they had to redesign everything.  Sigh.

The AT uses a 5-pin DIN and the PS/2 uses a smaller connector with the same
signals:

     1     CLK/CTS (open-collector)
     2     RxD/TxD/RTS (open-collector)
     3     Not connected or Reset
     4     GND
     5     +5V

Now the interface is bi-directional.  When the computer wants to send a byte
to the keyboard, it asserts RTS and releases CTS.  If you're lucky, the
keyboard isn't deciding to transmit at the same time and it responds by
giving 10 clock pulses (at about 10000 baud) on the CLK line.  The computer
shifts a frame out on TxD on rising clock edges.  The frame format is now 1
start bit, 8 data bits and 1 odd parity bit.  The keyboard takes RTS being
held low as the first start bit, and the first data bit should be sent on
TxD after the first clock edge is received.  Yes, now you need a full UART
for the keyboard interface since you have to both transmit and receive and
generate and check parity (but it's still not RS-232- that would have been
too logical).  Why do you need parity checking on a three foot long keyboard
cable?  Because collisions can occur since the lines are so overloaded with
signals with different meanings and parity provides the means for detecting
these collisions.

The AT documentation says that pin 3 is "reserved", so the keyboard has to
provide its own reset.  But on the original AT, pin 3 was still Reset and
IBM's own keyboards at that time needed Reset (original AT keyboards won't
work on some old clones because of this).  Don't ask me... I don't
understand why they did this.

The protocol on the keyboard interface is now much more complicated.  These
bytes are defined:

Commands

  ED <byte>                 Set leds depending on byte
                              bit 0 is Scroll lock
                              bit 1 is Num lock
                              bit 2 is Caps lock

  EE                        Echo EE (for testing?)
  F0 <mode>                 Select mode 1, 2 or 3
  F2                        Send keyboard I.D.
  F3 <byte>                 Set repeat delay and rate
                              byte is: 0ddbbaaa
                              delay is (dd+1)*250 msec
                              rate is (8+aaa)*2^bb*4 msec

  F4                        Clear buffer
  F5                        Restore default settings and wait for enable
  F6                        Restore default settings
  FA                        Acknowledge
  FE                        Error- please retransmit
  FF                        Reset keyboard

Status returns

  00                        Buffer overflow
  AA                        Self-test passed
  F0 <scan-code>            Release code
  FA                        Acknowledge last command
  FD                        Self-test failed
  FC                        Self-test failed
  FE                        Last command in error; re-send
  E0 scan/release code      Extended keys in Mode 2

The computer and keyboard must acknowledge each command and key code with
either FA if there was no error, or FE if the last command/key-code should
be re-sent.  There are three modes of operation for the keyboard, depending
on which scan code assignments you want (these can often be set by a switch
on the back of keyboard, except that if mode 1 is selected from the switch,
the protocol is eliminated an the keyboard works exactly like an original XT
keyboard- newer keyboards only support modes 1 and 3).  In mode 1, the
keyboard gives XT scan-codes.  The keyboard handles the cursor keypad (which
didn't exist on the XT) by simulating pressing or releasing a shift key
(depending on whether shift or num-lock are pressed) and sending codes from
the numeric keypad.  Mode 2 works like mode 1, except that when the keyboard
does the weird stuff with the numeric keypad it prefixes everything with E0
and the release codes are the scan-codes prefixed with F0.  In mode 3, each
key gets a unique code and the release codes work as in mode 2: the release
are the scan-codes prefixed by F0.

When the AT keyboard is first reset it's supposed to send an AA if its
self-test passed or FD or FC if it failed.  But before it does this, it
sends a continual stream of AAs with the parity incorrect.  Once the
computer sends an FE to indicate that there is a parity error, the keyboard
stops sending bad AAs and sends a correct AA or an FD or FC.  This sounds
like someone made a quick fix in the keyboard firmware for mis-matched reset
timing (the keyboard always finishes resetting before the computer so the
computer could miss the AA/FD/FC).


Q) 3.21  +Can I fake a keyboard so my computer will boot without it?


[From: [e-mail] (Joseph H Allen)]

() The IBM Keyboard - how do you use a computer without a keyboard?

Sometimes a PC needs to be set up as a "turn-key" system with no keyboard
for security reasons, or simply because the application doesn't need a
keyboard.  This causes a dead-lock problem when the system is booting: The
BIOS will detect that there is no keyboard and display the message "keyboard
failure - press F1 to continue," and the system becomes stuck.

There is usually a BIOS set-up option for disabling the keyboard test.
Check the manual for your motherboard.  If your BIOS does not have this
option, you're essentially screwed because there's no simple solution.  You
can't wire the DIN to fake the existence of a keyboard since the BIOS checks
for a self-test result code generated by the keyboard.  In fact, you would
have to implement a small protocol (byte-by-byte handshaking and ACK/NAK) to
simulate a keyboard up to its self test. It's conceivable that someone could
make a DIN connector with a small microcontroller in it to do this, but I
have never seen such a thing.  Another solution is to replace your BIOS with
one which has the keyboard test disable option.  However, you have to find
one which matches your motherboard.


S) 4.0 Storage/Retrieval Devices

Q) 4.1  Why do I lose x Meg on my hard drive?

[From: Mike Long <[e-mail]>]

The problem here is that there are two different measures of hard
drive storage, both called megabytes.  Computer hardware works on the
basis that one megabyte equals 2^20, or 1048576 bytes.  Hard drive
manufacturers, on the other hand, use a megabyte that has 1000000
bytes, because it makes the drive looks larger.  When buying a hard
drive, you should expect to lose almost 5% of what the manufacturer
claims the drive size to be.

The manufacturers are not totally at fault.  The first track of the
drive is used for the partition table and master boot record.  The
amount of data lost here depends on your drive parameters; usually
there are between 32 and 64 sectors (512 bytes/sector) on this first
track, so you lose between 16384 and 32768 bytes that way.

Additional space is taken up by two hidden files on your boot drive.
If you are running MS-DOS, these files are IO.SYS and MSDOS.SYS.  If
you are running PC-DOS, the names are IBMIO.SYS and IBMDOS.SYS (?).

[From: [e-mail] (Ralph Valentino)]

Many drives these days advertise unformatted capacity.  The actual
formatted capacity may be significantly lower than this as space is
taken up marking tracks, sectors, CRC's, etc.  Exactly how much lower
depends on the the size of the sectors.  For instance, placing 1k
sectors on the disk instead of the usual 512 byte ones may slightly
increase the usable storage space on the disk.  Note, however, that
many OS's insist you stick to the 512 byte sectors so this option is
best left alone.

A large number of drives also do auto-mapping of bad sectors; when a
sector goes bad, it will automatically use a spare it kept aside
during the format.  This is very handy as the OS never needs to deal
with the problem and some OS's, like DOS, will mark a whole cluster
bad when a single sector goes bad.  These spare sectors, as many as
one per track, remain hidden from the OS but still take up space on
your hard drive.

When you get to drives larger than 1.0 gig (SCSI), many host adapter
BIOS's can not deal with this as the BIOS was never designed to handle
more than 1024 cylinders, 64 heads, and 32 sectors per track. (1024 *
64 * 32 * 512bytes/sec = 1.0 gig).  Luckily, some OS's (like OS/2)
ignore the BIOS all together and read the actual geometry from the
disk itself.  If, however, you're not using such an OS and you notice
that you only have 1.0 gig available, you may want to check with the
manufacturer of your SCSI host adapter to see if a newer BIOS is
available.

Q) 4.2  *Should I get an IDE/floppy/SCSI/parallel port tape drive?
Q) 4.3  I have two floppies. Can I add a floppy based tape drive?

[From: [e-mail] (Herbst OMR)]

It depends. On all modern tape drives: yes. Some old tape drives
cannot do this (my old Jumbo). If you have one of these, you will have
to buy either a 4-floppy controller or a dedicated tape controller.

Q) 4.4  How fast is a tape drive? Will a dedicated controller improve this?

[From: [e-mail] (Herbst OMR)]

The tape connected through a floppy interface is limited to the floppy
speed.  On ATs 500Kbit/S. On old XT 250Kbit/S. With card support for
2.88MB floppy, 1Mbit/S. Many of the newer cards support this transfer
rate.

If the card operate at 500Kbit/S, a dedicated controller card will
speed up the tape by a factor of two.  In many cases, those cards do
hardware compression, helping even more.

Q) 4.5  What is QIC80, QIC40?

[From: [e-mail] (Herbst OMR)]

QIC stands for Quarter-Inch Cartridge. QIC80 is the standard for 80MB
tapes, QIC40 for 40MB tapes. Both standard allows for extended length
cassettes of 300ft which gives 120MB and 60MB respectively.

Q) 4.6  How come I can't fit as much stuff on my tape drive as they claim?

Most tape drives these days advertise capacity with an expected
compression ratio of 2:1.  If you are backing up compressed files
(.Z,.ZIP, .ARC, .JPEG, and so forth) then the drive's own compression
scheme will not be as effective.  For these cases, the actual capacity
of the tape will be closer to the "uncompressed" capacity.

A table from [e-mail] (Herbst OMR) shows:

  stated capacity     standard        tape length         # tracks

  80MB                QIC40           200ft (normal)      15
  120MB               QIC40           300ft (extended)    15
  160MB (rarely)      QIC80           200ft               28
  250MB               QIC80           300ft               28

  For all the recording density is 12500 ftpi; max tape speed is 90 ips.

A second reason is that some tapes assume you will be taking full
advantage of their "streamers".  Streaming collects a number of tape
blocks and writes them all at once, preventing the need for backing up
the tape after each block.  This positions the blocks closer together
on the tape.  If your backup program is slow, some streamers won't be
quite as effective.  If you hear the tape drive motor backing up the
tape alot on writes, this could be the case.

Q) 4.7  Are Colorado/Conner/Archive/... tapes compatible with each other?

[From: [e-mail] (Herbst OMR)]

If you use the same software: Yes. If you want to use different
software, then turn compression off. Compression done in software on
those drives is not compatible.

Q) 4.8  How does the drive/software know how long the tape is?

[From: [e-mail] (Herbst OMR)]

The magnetic tape has holes in it. Inside the cassette enclosure there
is a small mirror. The drive sends an IR beam through it. Near the end
of tape the drive receives it. If the IR receiver is dusted, the drive
may 'reel off' the cassette.

Q) 4.9  What are all those QICs?

[From: [e-mail] (Herbst OMR)]

(Thanks to Karl-Peter Huestegge and Jan Christiaan van Winkel)
QIC-11 is not an Industry Standard and there exist some incompatible
versions.

 Standard      Capacity      Tracks   Speed  Rec-density Flux-Trans Cartridges
 ----------------------------------------------------------------------------
 QIC-11     15/30MB (300ft)     4/9   90ips
            20/40MB (450ft)     4/9   90ips               6400ftpi  DC300XL
                                                         10000ftpi  DC300XLP
            27/60MB (600ft)     4/9   90ips              10000ftpi  DC600A

 QIC-24     45MB (450ft/137m)    9    90ips    8000bpi   10000ftpi
            55MB (555ft/169m)    9    90ips    8000bpi   10000ftpi
            60MB (600ft/183m)    9    90ips    8000bpi   10000ftpi  DC600A

 QIC-120   125MB (600ft/183m)    15   72ips   10000bpi   12500ftpi  DC600A

 QIC-150   155MB (600ft/183m)    18   72ips   10000bpi   12500ftpi  DC600XTD
                                                                    DC6150
 QIC-150   250MB (1000ft/305m)   18   72ips   10000bpi   12500ftpi

 QIC-320   320MB (600ft/183m)    26   72ips   16000bpi   20000ftpi  DC6320

 QIC-525   525MB (1000ft/305m)   26   72ips   16000bpi   20000ftpi  DC6525

* QIC-1000  1000MB (760ft)

* QIC-2GB

* QIC-10GB

Q) 4.10  Which QICs are read/write compatible?

[From: [e-mail] (Herbst OMR)]

 The left column should be read: "Tape drives designed for the QIC-???
 standard *should* be able to read/write the following Tape formats:"

 TAPE-DRIVES     |                     Tape - Formats                      |
 designed for:   | QIC-11 | QIC-24 | QIC-120 | QIC-150 | QIC-320 | QIC-525 |
 ----------------|--------|--------|---------|---------|---------|---------|
 QIC-11          |  R  W  |        |         |         |         |         |
 QIC-24          |  R  W  | R   W  |  R      |         |         |         |
 QIC-120         |  R  -  | R   -  |  R   W  |  R      |         |         |
 QIC-150         |  R  -  | R   -  |  R   W  |  R   W  |         |         |
 QIC-320         |  R  -  | R   -  |  R   W  |  R   W  |  R   W  |  ?   ?  |
 QIC-525         |  R     | R      |  R   W  |  R   W  |  R   W  |  R   W  |
 ---------------------------------------------------------------------------

===============
Ralph Valentino   ([e-mail])  ([e-mail])
Hardware Engineer,  Worcester  Polytechnic  Institute
Center for High Performance Computing, Marlborough MA